home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 16740 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  1.8 KB
  1. Path: news.compuserve.com!newsmaster
  2. From: 100754.2730@compuserve.com (Martin Aupperle)
  3. Newsgroups: comp.lang.c++
  4. Subject: Re: Is it OK to delete const *type pointers?
  5. Date: Thu, 11 Apr 1996 22:55:26 GMT
  6. Organization: CompuServe Incorporated
  7. Message-ID: <4kk6fr$91g@dub-news-svc-3.compuserve.com>
  8. References: <4k9g7c$fl9@arl-news-svc-5.compuserve.com>
  9. NNTP-Posting-Host: hd68-145.compuserve.com
  10. X-Newsreader: Forte Free Agent v0.56
  11.  
  12. Philippe Verdy <100105.3120@compuserve.com> wrote:
  13.  
  14.  
  15. >The following compiles under BC++ 4.0, 4.5, and 5.0:
  16. >int const *ptr = new int(1);
  17. >int const *arr = new int[10];
  18. >main()
  19. >{
  20. >  delete ptr;
  21. >  delete[] arr;
  22. >}
  23.  
  24. >Being const does not mean the object is read-only. Nor does
  25. >it mean that its value won't change. 
  26.  
  27. That's exactly what it means. 
  28.  
  29. >It only forbids writing to it directly without an
  30. >explicit const_cast<>. 
  31.  
  32. What do you mean by "writing to it directly?" For my objects, I only
  33. can change members, and this is not allowed for const objects.
  34.  
  35. >This cast however is an operator
  36. >which can be overriden to enforce const-ness, by returning
  37. >a non-const copy of the referenced object.
  38.  
  39. This is EXACTLY what I do not want to happen. The intention of the
  40. programmer was to change a object, and if this is not possible, he/she
  41. should receive an error. Usually, if you have a pointer to a const
  42. object, you typically are within a function, and there are also non
  43. const pointers in the calling function one level higher. If you
  44. silently make a copy, the calling function still has the unchanged
  45. object, which was not intended by the design. This goes unnoticed and
  46. can only be determined at runtime. 
  47.  
  48. BTW, who is responsible for deleting your "temporary" object?
  49.  
  50.  
  51. -----------------------------------
  52. Signatures are a waste of bandwidth
  53. -----------------------------------
  54.  
  55.